Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/networking/ip/ppp/DialupPPP.doc

Text File | 1992-07-24 | 67KB | 1,652 lines

                Dialup PPP
                Release 2.2
                Kirk Smith
                Purdue University
                June 1992

1.  Introduction

1.1 General

This software was developed to provide dialup on demand PPP over high
speed modems.  In many situations, leased lines are used to provide
TCP/IP links over significant distances.  With the advent of V.32bis
modems, and with this software, another alternative exists.  It
appears to the application that the modems remain connected all the
time (like a leased line). In reality, however, they disconnect
whenever there is no traffic. When a packet arrives at the interface
to be transmitted, and the modems are not connected, a connection is
made and the packets begin to flow again.

1.2 Audience

This file contains information for those intending to install and use
dp (Dialup PPP), and is not aimed at teaching you about TCP/IP networking,
although subjects which may be new to you such as routing and nameservers
will be covered.

1.3 History

The base for this software is several other free packages that have
been modified to support this purpose.  The dialup code came from the
BBN Dialup Slip.  The PPP program is from Carnegie Mellon University. The
kernel PPP streams driver came from Brad K. Clements. The TCP/IP
header compression support came from Van Jacobson from the University
of California.  Kirk Smith at Purdue University assembled all these
pieces, made them all work together, and added a number of features
beyond the original software.

1.4 Release Notes

1.4.1 Supported Platforms

The software has been running on SunOS 4.1.1 and works quite well. It
will probably not work on anything but SunOS4 (Solaris 1.0). It
relies on STREAMS support.  It is possible to make it work in a
non-streams environment, but this has not done that. The latest
version of the PPP (non-dial on demand) has support for 386BSD, and
this platform may be supported soon.

1.5 Commercial Software

Companies sell products that do things similar to this.  I believe
that this software incorporates some unique features and has value in
itself. However, if you want a supported product, you might want to
shop around. Morning Star Technologies is one company that I know of.
Try sending mail to [e-mail] for more information.
From what I can tell, they have a top notch product and top notch
support.

A mailing list "[e-mail]" is available.  To
subscribe to this list, send a message to
"[e-mail]". This list is a group of
people either using or thinking about using this software.

2. Operational Overview

The software known as Dialup PPP (or dp-2.2) consists of several
distinct modules.  This section will discuss how the modules fit
together and then will describe each module in more detail.

From the application standpoint, this software implements a network
interface.  Ethernet interfaces have names like ie0, le0, or le1,
etc. This interface has a name like dp0, dp1, dp2, etc.  While
ethernets are "Broadcast" networks, these is a "Point to Point"
networks.  This is important to consider when dealing with address
assignment and routing. In short, when you "ifconfig" a point to
point interface, you must provide an IP address for both the source
and destination.  Routes to the network never exist, but routes to
both ends of the interface may exist. For more information on this,
refer to the manual pages on ifconfig(8c), route(8c), and routed(8c).

This network is always "UP" from the perspective of "ifconfig". Under
normal conditions, network applications like "telnet" or "ftp" will
always see a network that is up, even if there is a slight delay
while modems are re-connected.

2.1 Normal Operation

If the modems are connected, this network interface looks like a
dedicated leased line Point to Point interface.  Packets flow from
the kernel networking software to the appropriate "dp" interface.
The kernel driver for that interface consists primarily of the "dpif"
streams module.  The packets then become streams messages and are
passed to the "pppasync" module. This module encapsulates the packets
according to the PPP specification, including the addition of a frame
check sum.  It then passes the packets on to the streams driver of
the particular serial port hardware.  The serial hardware passes the
byte stream onto the modem and out into the public telephone system.

In addition, packets can be sent from the user level PPP program
(called dp). These packets are sent through the "dpif" streams module
and on to the "pppasync" module where they are encapsulated,
checksummed, and passed to the serial port streams hardware to the
modem.

On the other end, incoming bytes are received by the serial port
streams driver and passed on to the "pppasync" streams module.  This
module collects the bytes together into packets and rejects packets
with bad checksums according to the PPP specification.  Then, packets
are passed on to the "dpif" streams module where they are identified
as being either IP packets or control packets.  IP packets are passed
through the "dp" interface to the kernel TCP/IP modules.  PPP control
packets are passed off to a user level PPP process for further
interpretation.

This series of modules basically multiplexes and demultiplexes
packets from the PPP programs and the kernel networking on both ends.

2.2 Establishing Modem Connections

Assume, for now, that the network is properly configured, and the
modems are not currently connected.  When packets arrive at the
interface to be transmitted to the other end, there is no "dpif"
stream associated with the interface. There is no specific serial
port associated with the network interface at this time.  This
corresponds to the DISCON (disconnected) state.  The packet is placed
in a network queue awaiting a successful connection.

A request is assembled for this packet.  The request is a separate
streams message which includes the interface name, the interface unit
number, a flag indicating to check authorization, the destination
address, a copy of the IP header and the next 4 bytes of the packet.
In both TCP and UDP, these next 4 bytes indicate source and
destination ports. This request is sent to a user level program
called "dpd" (Dialup PPP Daemon) through another streams device
accessed through "/dev/dp0". If "dpd" is not running or not accepting
messages on "/dev/dp0", then the networking code immediately returns
ENETDOWN (network down). Otherwise, the WAITING state is entered and
packets continue to be queued until the call completes.

When the "dpd" program is started, it reads the configuration file
"/etc/dp/config/dp-conf".  This contains information about each
network interface and each available modem.  So, when the request
arrives, the "dpd" program checks for authorization according to
the interface configuration.  If a call is not permitted, a FAILURE
status is returned to the network interface.  Otherwise, dpd reports
a CALL_IN_PROGRESS status and creates a child process to handle this
call.

An appropriate modem is selected according to the configuration (this
will be explained in more detail later), and the call is placed using
the appropriate dial script.  Once the call completes, the
appropriate login script is used to log into the remote computer.  A
special account is set up on the remote computer that uses the login
shell "/usr/etc/dplogin". This program reads the configuration in
"/etc/dp/config/dp-conf", performs simple synchronization with the
"dpd" at the other end and sets the call status to CALL_IN_PROGRESS.

Both the "dpd" and "dplogin" programs start the "/usr/etc/dp" program
on both ends.  They negotiate all the options according to their own
configuration. Once they have completed their negotiations, they
report the SUCCESS call status and mark the network interfaces as
ACTIVE.

If a call FAILURE status is reported, or a call wait timeout expires,
the interface is marked with FAILEDCALL status.  After an appropriate
timeout, the interface moves back to a DISCON status.  This enforces
a minimum time between call attempts.  However, if the call failed
because no modem was available, dpd reports a special NO_MODEM status
which is similar to FAILURE status except the interface immediately
moves to the DISCON status so that further call attempts can be made.

2.2 Timing Out Modem Connections

Several timeouts can be specified in the configuration file
"/etc/dp/config/dp-conf".  Among those are the timeouts which govern
when the modems should be disconnected.  These timeouts are handled
by the kernel "dpif" module.  When the kernel decides to disconnect a
given interface, it sends a hangup signal (SIGHUP) to the "dp"
process which shuts down the link.  The operation of each timer will
be described. Each timeout is given in seconds and is specified in
the configuration file. We have found that this particular
combination of timers is highly effective in our typical use.  It
allows reasonable timeouts for interactive use, while quickly timing
out calls that were made for batch operations.

2.2.1 Inactivity Timer

The simplest timeout mechanism is the inactivity timeout.  If no
packets have been sent or received within a given time interval, then
the modems are disconnected.  This is usually relatively long,
roughly on the order of 2 to 3 minutes.

2.2.2 TCP Close Timer

The kernel keeps track of TCP/IP connections.  Each TCP/IP connection
is characterized by a distinct source and destination address and
port. During the life of a TCP/IP connection, packets are exchanged
with certain bits set in the header to indicate the creation and
deletion of these logical connections.  The interesting parts of the
header are the SYN, FIN, and RST bits.  The software monitors the
TCP/IP connections in progress.  By noting the passage of SYN, FIN,
and RST bits in TCP/IP headers, we keep a count of the number of
active TCP/IP connections. When that connection count goes to zero,
we assume that everyone has finished using the network interface for
now, and a fast timeout is enabled. This shorter timeout will
disconnect the modems if no packets are sent or received over an
interval shorter than the normal inactivity timeouts. We have set
this interval as small as 5 seconds and it works quite well

2.2.3 Non TCP Timer

Not every network application uses TCP, so consideration is made for
that case. In the case of no TCP connections, but non-TCP traffic is
flowing, a separate inactivity timeout can be specified.  This is
usually on the same order as the TCP Close timer, but perhaps a
little longer depending on the applications in use.

3. Source Code Overview

3.1 "h" directory

This directory contains include files that are used by several of the
programs that comprise this distribution.  The files dp_str.h,
if_ppp.h, ppp_str.h, slcompress.h, and slip_var.h need to be copied to
/usr/sys/sys as part of the kernel build procedure.

3.2 "dp" directory

This directory contains a slightly modified version of the CMU PPP
code. In release 2.0, it was based on "ppp" patch level 4, but under
release 2.2, it is based on "ppp" patch level 6.

The modifications to the standard PPP are small, but are necessary
for this mode of operation.  The "dp" program takes all the flags
that apply to the "ppp" program.  In addition, if the "dialup" flag
is given to dp, it modifies the behavior in the following ways:

- The name of the network interface is dp0, dp1, etc., instead of
ppp0, ppp1, etc.

- When an interface is brought up, it executes a SIOCCALLSTAT ioctl
which is specific to the dialup PPP software.

- When a normal PPP interface is brought down, it marks the network
interface as DOWN and removes the appropriate route.  For dialup PPP
interfaces, however, the interface always appears to be UP and the
route remains installed.

3.3 "dpd" directory

This is originally based on the diald program from BBN.  It has been
heavily modified to handle PPP rather than slip, and to handle the
different kernel interfaces.  This section will describe the major
differences in functionality.

The BBN code had a good expect script capability for doing the
dialing. This capability has been expanded somewhat to allow better
error handling. The "recv" directive has been modified to accept any
number of alternative strings.  One use this to accept all known
return codes from the modem. In addition, the timeout value on the
"recv" can now take on a value of 0. This means to only receive input
that has been already received when the "recv" is executed.  Use of a
"replay" followed by a "recv "string" 0" will immediately either succeed
or fail based on input received since the last "mark". An example of this
is the following:

    mark
    {
    alternate
        recv "CONNECT" "BUSY" "NO CARRIER" 30
    alternate
        log "Modem Timeout"
        abort
    }
    {
    alternate
        replay
        recv "CONNECT" 0
        go
    alternate
        replay
        recv "BUSY" 0
        log "Busy"
        abort
    alternate
        replay
        recv "NO CARRIER" 0
        log "No Carrier"
        abort
    }

This segment of a script will wait up to 30 seconds to accept either
"CONNECT", "BUSY", or "NO CARRIER", then immediately do the correct
branch.  This was impossible to handle in a timely way using the
original code.

The connection requests sent from the kernel to the "dpd" program can
include more than the IP header.  This was done to accomodate any
future enhancements that would screen connection requests based on
TCP or UDP port numbers.

The uucp locking conventions have been updated to match those in use
by the Sun version of uucp.  This is important to allow several
programs to share the available modems with the kernel networking.

A new flexible configuration file allows setting of many new options.
There will be section devoted to this configuration file which will
describe the options in detail.

The timeout mechanisms have been expanded.  A "call wait" timeout is
supported for the maximum waiting period between a call request and
the completion of the call.  Once a call has failed, a "failed call"
timeout indicates the time to wait before initiating a new call. The
activity timeout is represented by one of 3 timeouts including
"inactivity", "tcp close", and "non tcp", representing the conditions
when TCP connections are active, no TCP connections are active, and
non TCP traffic is active.

The concept of a modem has been expanded to include a modem rotary. A
rotary is a group of modems that are used in a round robin fashion.
With a bank of modems and phone lines, there are basically two ways
to pick which modem to use next:  "first available" and "next
available". The "next available" option corresponds to a "rotary", a
round robin selection, and can be used in order to be more tolerant
of a single modem or phone failure.  Given modems 1 to N, if modem
number 1 fails, the "first available" selection will always fail and
the "next available" selection will fail 1 out of N times.

SunOS allows use of a single modem for both dial in and dial out
through the use of two minor device numbers for each port.  This
facility has been completely integrated into this software so that a
single port can be easily used for both incoming and outgoing calls.

A new program "dplogin" is included which shares a number of
functions with "dpd".  "dplogin" is used as a login shell for
incoming calls and uses the same configuration file as "dpd".  It
handles locking and logging in a compatible way.

A call log file is now generated for both incoming and outgoing
calls. Each line of the file corresponds to a successful call and
includes the following information: remote site name, tty device,
date and time of initiation of connection, total connect time,
initiating program (dpd or dplogin), protocol and port of initiating
request (like tcp/smtp), and for both input and output, a report is
given of number of packets, bytes, and errors. The protocol and port
information is only available for outgoing calls.  This information
can be very useful for analyzing call patterns and minimizing costs.

An auxiliary program facility is provided.  If so configured,
whenever a modem connection is made, an auxiliary program can be
run.  This program could, for instance, check queues for outgoing
traffic and make use of the the connection to transfer mail, print
jobs, or other similar queued files. This could be easily tuned to be
site specific to reduce the number of calls made by taking advantage
of connections when they happen.

3.4 "sys" directory

The sys directory includes the kernel modules, including the
following:

3.4.1 ppp_async.c

The "pppasync" streams module, which is used in conjunction with
both the original "pppif" module and the new "dpif" module.

3.4.2 dp_if.c

The new version of ppp_if.c which has been heavily modified to
support the dialup on demand mode of operation. dp_if.c is based
originally on the ppp_if.c module from Clarkson University and Brad
Clements.  It has been expanded in several ways.

The connection status of each interface is now handled and a number
of timeouts are implemented.  The timeouts include the following:

callwait:    time to wait for a call to complete
failedcall:    time to wait before trying another call
inactivity:    disconnect after no packets in A seconds.
tcp_close:    disconnect C seconds after last TCP connection is closed
        and no packets.
non_tcp:    disconnect U seconds after last non-TCP packet given no
        activity and no TCP connections.

The timeouts can be set from the dp configuration file.

In addition, a completely new module keeps track of TCP connections
in progress and will notice when all connections close and the line
can be disconnected using one of the "fast timeouts" (tcp_close or
non_tcp).

The Van Jacobson header compression code is included and works well
with this package.

Included within dp_if.c is a driver for the "pppdial" streams device
that allows the kernel to request the initiation of calls from the
"dpd" program.

3.5 "dptrace" directory

Dptrace is a simple program that prints the request trace file.  As
each dialup request arrives through /dev/dp0, the dpd program writes
the current time and the current request to the file
"/var/adm/dp/req.trace". This program reads that file and formats the
requests into a readable format. The program can be helpful in
debugging and tuning the network.

3.6 "modem" directory

This directory contains a program to set modem options on Hayes
compatible modems.  The "setmodem" command can be invoked as:

    setmodem [-v] scriptfile device [baud]

Scriptfile contains a number of AT commands that will be fed to the
modem. The setmodem program knows enough to expect OK returns from
the modem and waits until the OK to proceed to the next AT command.

Scripts for the telebit T1600, T3000, and WorldBlazer modems are provided
and have been tested.  You can modify these further to suit your configuration.

In addition, there is a shell script "initmodem.sh" which can be
invoked as:

    initmodem scriptfile outdev indev [baud]

The scriptfile is the same as in setmodem, and the outdev corresponds
to the device in setmodem, but the indev is the login side of the
same device that is given in /etc/ttytab.  This script first edits
/etc/ttytab to turn the login off for that port.  This allows
everything to work correctly with the softcarrier options, etc.  The
program resets the port before completion and generally is the preferred
way to handle the initialization of devices.

3.7 "aux" directory

The aux directory contains the sources for auxiliary programs that
can be run when connections are established.  If so configured in the
"/etc/dp/config/dp-conf" file, whenever a modem connection is made,
an auxiliary program can be run.

Currently, the only program provided is a program called ckmailq.
This looks in the mail spool directory for outgoing mail that is not
currently being processed.  If such mail exists, it starts up
sendmail with the proper options.

Other similar programs could be written for other queued traffic such
as print jobs or uucp requests.  This can be used to "poll" for SMTP
mail when a remote site can't initiate calls on it's own.

4. Building & Installation

In this release there are two ways to install dp. One is to use the
loadable module support in the current version, but this has known
problems with unloading (which may not be a problem in most situations).
The other method is to install the dp drivers directly into the kernel
with a kernel rebuild.  This option will go away with Solaris 2.0, but
works quite will under Solaris 1.0, and has no known problems.
In the end, you will need to use the method that is most appropriate
in your situation. Below, both methods are covered in detail.

In either case, the rest of dp must be built and installed in the way
given below.

4.1 Loadable Module Version Install

4.1.1 Building & Installing

In most cases, for SunOS 4.1.x at least, dp should build "out of the
box", and you should just do this:

*    According to local policy, create a new group called "ppp", we
    suggest an id of 600. This would normally be done by adding an entry
    to "/etc/groups" or adding an entry on the NIS master if you use
    that. For more details see section XXX.

*    Unpack the distribution, which creates a directory called dp-2.2/

*    cd to dp-2.2/

*    type "make" and make sure there were no errors, then

*    Become "root", and type "make install", which will create all the
    necessary directories and copy the files required across setting the
    correct ownerships and permissions.

4.1.2 Using Loadable DP

For general configuration details you should proceed to section XXX,
but in addition you have to set up your system to load the modules at
some stage, usually at boot time. To run from "/etc/rc.local" you
should add the following lines to the file:

    if [ -f /etc/dp/script/startdp ]; then
        /etc/dp/script/startdp
        echo "started dialup PPP"
    fi

4.2 In-Kernel Version Install

For whatever reason, it may be necessary to install the dp modules in
the kernel. The main reason is that the loadable modules are not
fully supported at this release, or local policy may curtail the use
of them in future release. This section goes through manual
installation procedure.

The dp network interface must be installed in the kernel. To install
this software, we must reconfigure, rebuild, and reboot with a new
kernel (/vmunix).

4.2.1 /usr/sys/conf.common/files.cmn

So that the "config" program knows where to find the drivers, the
following lines must be added to the end of the file
"/usr/sys/conf.common/files.cmn":

    os/dp_if.c        optional dp
    os/ppp_async.c        optional dp

4.2.2 /usr/sys/sun/conf.c

This file will contain the description of the pppdial streams
device. This device allows communication between the kernel network
interface and a user program "dpd" which makes calls and establishes
connections.

Before the definition of the cdevsw array, a number of #defines are
set up for each device.  After the last such setup and before the
cdevsw array, place the following lines:

#include "dp.h"        /* Dialup PPP */
#if NDP > 0
extern struct streamtab ppp_dialinfo;
#define    dptab    &ppp_dialinfo
#else
#define    dptab    0
#endif

The cdevsw array contains an entry for each supported device.  The
supported devices and the number of such devices varies somewhat from
release to release. In SunOS4.1.1, the last supported device is 103,
as indicated in a comment to the right of the device definition.
Assuming no other local devices, then, the Dialup PPP device would be
device number 104 and defined as follows:

    {    /* Dialup PPP */
    nodev,    nodev,    nodev,    nodev,        /*104*/
    nodev,    nodev,    nodev,    0,     dptab,    0,
    },

The exact position in the array does not really matter as long as you
use the correct number when you create the device.  In this case, 104
is the major number of the device and will be used later when the
device is created.

4.2.3 /usr/sys/sun/str_conf.c

This file defines the 3 streams modules involved.  Dialup PPP uses
"dpif", "pppdial", and "pppasync".

Near the beginning of the file, there are a number of #include
directives. After the last one, place the following line:

    #include "dp.h"

Then, there are a number of extern definitions based on #if
directives. After the last one, place the following lines:

    #if NDP > 0
    extern struct streamtab dp_ifinfo;
    extern struct streamtab ppp_dialinfo;
    extern struct streamtab ppp_asyncinfo;
    #endif

Then, there is a fmodsw array defined.  This array defines all the
streams modules in the system.  Near the end of this array,
before the loadable modules are defined (VDDRV), put the
following lines:

    #if NDP > 0
        { "dpif", &dp_ifinfo },
        { "pppdial", &ppp_dialinfo },
        { "pppasync", &ppp_asyncinfo },
    #endif

4.2.4 /usr/sys/sun4c/conf/CONFIG_NAME

Each kernel is built from a configuration file with some name.  By
default, when SunOS boots, it places that name in a comment in the
file /etc/motd. You can tell which configuration was used to build
the current system by looking at that file.

It is probably best to copy that configuration file to a new file,
perhaps with "_DP" appended to the name.  For purposes of discussion,
we will call the new configuration "SYS_DP".  Then edit the new
configuration file and add the following lines:

#
# Point to Point Protocol (PPP) devices
#
pseudo-device    dp    init    dp_attach

If you want more than one interface (like for a central hub), just
put the number after "dp".  For instance, for 8 interfaces, use the
line:

pseudo-device    dp8    init    dp_attach

4.2.5 New Source Files

From the "sys" directory in the distribution, copy the following
files to the "/usr/sys/os" directory:

    dp_if.c
    ppp_async.c

From the "h" directory in the distribution, copy the following files
to the "/usr/sys/sys" directory".

    dp_str.h
    if_ppp.h
    slip_var.h
    slcompress.h

4.2.6 Configuring and Compiling

In the directory "/usr/sys/sun4c/conf", run the command:

    /usr/etc/config SYS_DP

Use the name of the file you edited in the previous step in place of
"SYS_DP". Then, change to the directory "../SYS_DP", and run make.
You should get a new kernel "vmunix".  In order to install the new
kernel on your system, you should save a copy of the old kernel with
"cp /vmunix /vmunix.old", then "cp /usr/sys/sun4c/SYS_DP/vmunix
/vmunix".  Then, reboot using the "shutdown" or "reboot" command.

4.2.7 Creating Devices

Only one new device needs created in the /dev directory.  This is the
"pppdial" streams device that is used to pass dial requests from the
kernel "dpif" module to the "dpd" program.  It should be created with
a major number that is dependent on the exact contents of the
"/usr/sys/sun/conf.c" file. For this example, we will assume the
major number is 104.  These are the commands you would use:

    # /usr/etc/mknod /dev/dp0 c 104 0
    # /usr/etc/chown root.staff /dev/dp0     chmod 600 /dev/dp0

4.3 System Files

A number of system files need entries added according to your own
setup. These files will be discussed here.

4.3.1 /etc/passwd & /etc/group

This procedure may vary slightly depending on the use of NIS or
shadow password files.  But, basically you will be defining users and
groups much like you would for a new system user.  Feel free to adapt
this procedure to your specific arrangement.

You should have defined a new group called "ppp" earlier in the
installation if you used the loadable module support, otherwise
assign a suitable id. In our case, we used the group id 600.  For
each remote site that will be calling in, you need to create a login.
We have used the convention that PPP logins all start with the
letter 'P'.  This has made it easy to identify it as a "special" sort
of login when looking at the output of "who" or "finger".

Assume that we have 2 remote sites: "rem1" and "rem2".  We have
selected available user id's 601 and 602, respectively.
Additionally, we have selected group id 600 for group "ppp".  The
"/etc/passwd" file entries would take the following form:

    Prem1:*:601:600:PPP Remote 1:/var/adm/dp:/usr/etc/dplogin
    Prem2:*:602:600:PPP Remote 2:/var/adm/dp:/usr/etc/dplogin

The entry in the "/etc/group" file would look like this:

    ppp:*:600:Prem1,Prem2

After creating these entries, we would use the command "passwd Prem1"
to set the password for the "Prem1" account, and similarily for
"Prem2".

4.3.2  /etc/rc.boot

At some point in the boot process, you must arrange to run ifconfig
on all your "dp" interfaces.  Sun has arranged code in /etc/rc.boot
to do all the ifconfig's automatically, but it needs minor
modification to make it work. You can simply add the ifconfig lines
directly in one of the rc files (before starting dpd), or you can
modify /etc/rc.boot and use the Sun scheme. Here are the
modifications necessary to /etc/rc.boot. The line:

    hostname="`shcat /etc/hostname.??0            2>/dev/null`"

needs changed to:

    hostname="`shcat /etc/hostname.?e0            2>/dev/null`"

Later, this file messes with IFS and then looks for files of the form
"/etc/hostname.*".  The lines:

    IFS="$IFS."
    set `echo /etc/hostname\.*`

need changed to:

    SIFS=$IFS
    IFS="$IFS."
    set `echo /etc/hostname\.*`
       IFS=$SIFS

The line:

    ifconfig $1 "`shcat /etc/hostname\.$1`" netmask + -trailers up

needs changed to:

    ifconfig $1 `shcat /etc/hostname\.$1` netmask + -trailers up

In the file "/etc/hostname.dp0", you need to place the source and
destination addresses for the first PPP link.  The source address is
the address on the local machine, and the destination address is the
address on the remote machine. These addresses can be hostnames from
the hosts database or internet numeric dot notation.  Create one of
these files for each PPP link.

4.3.2 /etc/rc.local

After the "ifconfig" commands are run at boot time, before using the
PPP interfaces for anything else, you must start the Dialup PPP
Daemon (PPP). In /etc/rc.local, there is a line similar to:

    ifconfig -a netmask + broadcast + > /dev/null

Right after that line is a good place to start dpd.  The lines to add
look like this:

    #
    # Start Dialup PPP Daemon.
    #
    if [ -f /usr/etc/dpd -a -f /etc/dp/config/dp-conf ]; then
        /usr/etc/dpd
        echo 'starting Dialup PPP Daemon.'
    fi

4.3.4 /etc/hosts

In short, you need an entry in "/etc/hosts" for each "dp" interface.
Each PPP link is a network in it's own right.  So, it to be assigned
a unique internet IP number for each end.

For broadcast networks, a network address is assigned for each
physical network. Host numbers are chosen for each host on the
network.  For an example class C addresses 199.10.11.14 and
199.10.11.52 are both on the same IP network (199.10.11). These
addresses represent hosts 14 and 52 on that network. IP routers know
how to get to the 199.12.13 network and pass packets on to the
appropriate gateway.  Once the packets get to that network, they are
then routed to host 14, 52, or whatever.

In contrast, the number of hosts on a Point to Point network is
always 2. So, in IP routing, we never actually use a route to the
network.  We just use a route to each individual address (both ends).
So, if we are administering several Point to Point networks, we can
use a single IP network, and assign pairs of addresses.  For
instance, assume we have a class C network 199.10.20 assigned for PPP
links.  Our first link could have the addresses 199.10.20.1 and
199.10.20.101.  Our second link could have the addresses 199.10.20.2
and 199.10.20.102.  We need two addresses for each link since we need
to assign an address to each end.  Using addresses differing by 100
for both ends of the link has proven to be a convenient convention
for us. It helps us to keep track of things when dealing with a large
central hub.
So, let's say we have a hub machine called "hub", with 2 PPP links,
"dp0", and "dp1" serving the machines "rem1" and "rem2".  Each of
these remote machines have a single PPP interface "dp0".  Using the
addresses from the previous examples, we would have /etc/hosts
entries as follows:

    199.10.11.14    hub hub-le0
    199.10.20.101    hub hub-dp0
    199.10.20.102    hub hub-dp1
    199.10.20.1    rem1 rem1-dp0
    199.10.20.2    rem2 rem2-dp0

These are just guidelines and address assignment can be done in a
different ways based on local conventions and local politics.  In
addition to the hosts file, many sites will also be using the DNS
(Domain Name System). The DNS files need updated to reflect the new
network addresses in a similar way.  In addition, routing can be
quite different based on the protocols involved.  For further
discussion about DNS and routing, see the later sections detailing a
sample configuration.

5.  Configuration

5.1  "dp-conf" file

When, the programs "dpd" and "dplogin" are started, they read a
configuration file "/etc/dp/config/dp-conf".  This file has a
definition for each interface, each modem, and optionally a number of
modem rotaries.

An definition of begins with a line beginning in the first column.
Continuation lines must begin with white space (SPACE or TAB
characters). Comments can be placed anywhere in a line and must begin
with #. Strings can be delimited by double quote characters (""),
if necessary.

For a given definition, each variable is given a value with a the
variable name, an equal sign, and the value.  For instance, the first
entry in the definition for the dp0 interface is:

    IF=dp0

This section defines all the possible options, their possible values,
and gives some examples to show how they might be used.

5.1.1  Interfaces

Each interface corresponds to a logical network connection to a
single remote site.  Provisions are made in the interface definition
to specify how calls should be made and received in order to handle
traffic on that interface.

5.1.1.1  IF

The IF variable must be the first entry in the interface definition.
It's value is the name of the network interface (e.g. IF=dp0).

5.1.1.2  SYS

The SYS variable can be optionally set to indicate a system name to
be used when making log entries.  If the SYS variable is not
explicitly set, it is defaulted to be the internet name of the
remote site (as returned by gethostbyaddr()), or if that fails, the
internet address of the remote site in dot notation.

5.1.1.3  MODEMS

The MODEMS variable specifies the modems or modem rotaries that
should be used to make calls for this interface.  At least one modem
or modem rotary must be specified.  If more than one modem or modem
rotary is specified, when a call request is made, each entry in the
list is tried in turn until an available modem is found.  The names
used in this list must correspond to a MODEM or ROTARY definition as
specified in the configuration file.

5.1.1.4  PHONE

The PHONE variable specifies the phone number that will be passed to
the DIAL_SCRIPT as defined by the modem in use on a particular call.

5.1.1.5  LOGIN_SCRIPT

The LOGIN_SCRIPT variable specifies an expect script that will be
used to log into the remote system for the purposes of establishing a
PPP connection. These scripts are found, by default, in
"/etc/dp/script" and will be described in detail later.

5.1.1.6  LOGIN_ARGS

The LOGIN_ARGS variable is a comma separated list of arguments to the
expect script as defined by the value of LOGIN_SCRIPT.  This is
typically the login and password on the remote machine.

5.1.1.7  LOGIN

The LOGIN variable has practically nothing to do with the
LOGIN_SCRIPT and LOGIN_ARGS variables, both of which deal with
outgoing calls.  The LOGIN variable, instead, is set to allow a
particular login id to be used to call in to establish a PPP
connection.  When dplogin is called, it knows what account was used
to log into the system.  It searchs the configuration file for an
interface where the LOGIN variable is set to that same account.

5.1.1.8  TRACE

The TRACE variable can be used to specify a trace file for the
calling script.  If there is a problem with establishing a particular
connection, this variable can be set to see what characters are being
transfered when the DIAL_SCRIPT and LOGIN_SCRIPT are both run.

5.1.1.9  ACCESS

An ACCESS file can be specified.  This file defines a number of
additional variables and can be used to limit the conditions for
which calls will be made.  This file is located, by default, in the
"/etc/dp/config" directory. This file will be described in detail in
the next section.

5.1.1.10  PPP_ARGS

When the PPP program "dp" is started by dpd or dplogin, you can
specify additional arguments to be put in the argument list.  For
instance, if you are using dp.2.2 to talk to a dp.2.0 installation,
the default header compression negotiation has changed with the new
patch level of PPP. So, in the 2.2 configuration file, you can put
the line:

    PPP_ARGS=vjmode,old

This will talk to a patchlevel 4 PPP correctly and the option negotiation
will function properly.

5.1.1.11  AUX

The AUX variable specifies an auxiliary program that will be run
after a PPP link is established for a particular interface.  The
default location for these programs is "/etc/dp/aux".  An example
program is provided that checks the sendmail queue for queued
messages.  This could be run to make sure mail messages are sent out
whenever the link is established for any reason.

5.1.1.12  AUX_ARGS

Arguments may be provided to AUX program by specifying them here as
a comma separated list of arguments, much like the PPP_ARGS varialble.
The last argument provided to the AUX script is always the system name
from the SYS variable.

5.1.1.13  LOG_LEVEL

The Log Level can be set when dpd is started.  The LOG_LEVEL variable
overides the current log level for calls made to this system.  In addition,
dplogin will set the same LOG_LEVEL for incoming calls.

5.1.1.14  ASYNC_MAP

The PPP program can be setup to avoid using certain control characters in
the case of links that aren't totally transparent.  This takes the form of
a 8 digit hexadecimal string representing a 32 bit number.  The lowest
to highest order bits of the number correspond to the ASCII character
represented by 0 through 31.  If the bit is set, that character will
not be transmitted on the line, but will instead be replaced by a special
escape sequence.  By default, the ASYNC_MAP is set to 0, which means pass
all characters since we have a totally transparent link.  This variable
applies to all calls made to this system independent of which modem was used.

5.1.2  Modems

A modem entry is required for each serial device that can be used to
establish a connection to a remote system.

5.1.2.1  MODEM

The MODEM variable must be the first entry in the modem definition.
It's value is an arbitrary (hopefully descriptive) name.  This same
name is used in the interface definition as a value for the MODEMS
variable.

5.1.2.2  DEV

The DEV variable is set to the physical serial device name path name.
 If the entry does not begin with a "/", then it is assumed that the
device appears in the "/dev" directory.  Sun has a scheme for using
the same line for dial out and dial in.  For most configurations, you
should use the name of the dial out device.  This is the one with the
0x80 bit set in the minor number. If necessary, you can make the
dialout device for a given login port. As an example, assume we are
using "ttya" and we want to make a dialout device "cua0". Here are
some example commands run as root to make the device.

    # ls -lg /dev/ttya
    crw--w--w-  1 root     wheel     12,   0 May 21 12:30 /dev/ttya
    # /etc/mknod /dev/cua0 c 12 128
    # chmod 660 /dev/cua0
    # /etc/chown uucp.uucp /dev/cua0
    # ls -lg /dev/ttya /dev/cua0
    crw--w--w-  1 root     wheel     12,   0 May 21 12:30 /dev/ttya
    crw-rw----  1 uucp     uucp      12, 128 May 21 12:30 /dev/cua0

Then, you would put "DEV=cua0" in your modem definitions to use this
device.

5.1.2.3  DIAL_SCRIPT

The DIAL_SCRIPT variable is the name of a script file.  By default,
these files are located in "/etc/dp/script".  This script will be
used to interact with the modem and make the call.  The phone number
is passed as the first and only argument to the script.

The next section describes modem rotaries.  If all the modems in a
rotary use the same DIAL_SCRIPT, it is not necessary to set each one
individually.  The DIAL_SCRIPT variable is set from the ROTARTY
definition.

5.1.2.4  BAUD

The BAUD variable is the baud rate to use for outgoing calls on this
modem.

The next section describes modem rotaries.  If all the modems in a
rotary use the same baud rate, it is not necessary to set each one
individually.  The BAUD variable is set from the ROTARTY definition.

5.1.2.5  DIAL_CHARMAP

This variable is set in order to map characters embedded in phone numbers
to the appropriate modem control character.  For instance, it may
be a common practice to include a '=' in phone numbers when you have to
wait for a secondary dial tone and a '-' when you just have to pause for
a second.  For Telebit modems, then the mapping would be performed with:

    DIAL_CHARMAP==W-,

which means wait for dial tone is 'W', and a short pause is ','.
This allows modems of different brands to be used without undue
difficulty.

5.1.2.6  ASYNC_MAP

The PPP program can be setup to avoid using certain control characters in
the case of links that aren't totally transparent.  This takes the form of
a 8 digit hexadecimal string representing a 32 bit number.  The lowest
to highest order bits of the number correspond to the ASCII character
represented by 0 through 31.  If the bit is set, that character will
not be transmitted on the line, but will instead be replaced by a special
escape sequence.  By default, the ASYNC_MAP is set to 0, which means pass
all characters since we have a totally transparent link.  This variable
applies to all calls made with this modem.

5.1.3  Modem Rotaries

If you are administering a central hub machine with several modems,
you may wish to define a modem rotary.  When defining the interfaces,
you can set the modem variable to a list of modems (or rotaries).
Each one will be tried in turn until an available modem if found.
For a large number of modems, this is not very tolerant to hardware
failures.  If the first modem in the list is broken, calls will
always fail.  This approach is sometimes called using the "first
available" modem.

An alternative approach is to define modem rotaries.   A rotary is
best described as a "next available" approach.  The software keeps
track of the last modem used, and always starts with the next modem
in the list.  When the end of the list is reached, the first modem
becomes the next modem. This reduces overhead of finding a free modem
and insures that a bad modem will not totally shut down
communications.

5.1.3.1  ROTARY

The ROTARY variable must be the first entry in the modem definition.
It's value is an arbitrary (hopefully descriptive) name.  This same
name is used in the interface definition as a value for the MODEMS
variable. Modems and rotaries can both be listed in the MODEMS
variable equally well.

5.1.3.2  MODEMS

The MODEMS variable is set to a comma separated list of one or more
modems. The entries in the list are the names of the modems as
defined by their MODEM variable.  All entries in this list must be
modems.  Other rotaries cannot be used here.

5.1.3.3  DIAL_SCRIPT

The DIAL_SCRIPT variable is the name of a script file.  By default,
these files are located in "/etc/dp/script".  This script will be
used to interact with the modem and make the call.  The phone number
is passed as the first and only argument to the script.

This entry will be used if the MODEM definition does not define a
DIAL_SCRIPT itself.  This is useful when a pool of modems are all the
same type and the DIAL_SCRIPT is the same for all of them.

5.1.3.4  BAUD

The BAUD variable is the baud rate to use for outgoing calls on any
modem in this rotary.

This entry will be used if the MODEM definition does not define a
BAUD itself.  This is useful when a pool of modems are all the same
type and the baudrate is the same for all of them.

5.1.3.5  DIAL_CHARMAP

This variable is set in order to map characters embedded in phone numbers
to the appropriate modem control character.  For instance, it may
be a common practice to include a '=' in phone numbers when you have to
wait for a secondary dial tone and a '-' when you just have to pause for
a second.  For Telebit modems, then the mapping would be performed with:

    DIAL_CHARMAP==W-,

which means wait for dial tone is 'W', and a short pause is ','.
If all the modems in a rotary are of the same brand, it is convenient
to set this variable in the rotary definition rather than setting it
in each modem definition.

5.1.3.6  ASYNC_MAP

The PPP program can be setup to avoid using certain control characters in
the case of links that aren't totally transparent.  This takes the form of
a 8 digit hexadecimal string representing a 32 bit number.  The lowest
to highest order bits of the number correspond to the ASCII character
represented by 0 through 31.  If the bit is set, that character will
not be transmitted on the line, but will instead be replaced by a special
escape sequence.  By default, the ASYNC_MAP is set to 0, which means pass
all characters since we have a totally transparent link.  This variable
applies to all calls made with any modem in this rotary.  If all the modems
in a rotary are of the same brand, it is convenient to set this variable
in the rotary definition rather than setting it in each modem definition.

5.2  Access Files

An access file can be defined to describe the conditions when a call
is permitted and to set the timeouts appropriately.  For instance, if
you have some sites that are long distance toll calls, and some that
are local calls, you may wish to have shorter timeouts on the toll
calls than on the locals.

The format of the access came from the BBN DialupIP software.  It has
been expanded in several ways, but it still looks pretty similar.
Aside from several small changes in the existing options, a series
of timeout specifications have been added.

5.2.1 Timeouts

There are eight timeouts which can be specified, three that can
be set separately for incoming and outgoing calls, and 2 more that only
make sense for outgoing calls.  Here is a sample section from a access
file showing all 8 timeouts:

    #
    # Connection Timeouts
    #
    failedcall         25    # time to mark network as down after failed call
    callwait         50    # time to allow for call to go through
    #
    # Activity Timeouts
    #
    dial:inactivity    180    # time to let the connection sit idle
    dial:last_close      6    # fast timeout after last TCP close
    dial:non_tcp     10    # fast timeout for non-TCP traffic
    answer:inactivity    600    # time to let the connection sit idle
    answer:last_close    180    # fast timeout after last TCP close
    answer:non_tcp    180    # fast timeout for non-TCP traffic

Since we are not dialing 800 numbers, we are paying for calls made.
In that case, we set short timers so that disconnections are prompt.
For incoming calls, we set some limits just to keep the modem pool from
being tied up.

5.2.1.1 Callwait

When the kernel "dpif" module requests a call be placed by "dpd", the
kernel starts the call wait timer.  If no status has been reported from "dpd"
within "Callwait" seconds, it is equivalent to receiving a "FAILURE" status
from "dpd".

5.2.1.2 Failedcall

After a FAILURE status or after the expiration of the Callwait timer,
the interface is marked with the FAILEDCALL status.  With that status
set, no calls will be attempted.  After "Failedcall" seconds, the interface
status is marked as DISCON, and call attempts will again be made.

5.2.1.3 Inactivity

If no packets have been sent or received through a PPP interface within
"Inactivity" seconds, PPP is terminated and the interface is marked as DISCON.

5.2.1.4 Tcp_close

TCP packets contain information about connections starting and ending.
A count of active connections is maintained for each interface.  When
this count goes to zero, if no packets have been sent or received within
"Tcp_close" seconds, PPP is terminated and the interface is marked as DISCON.

5.2.1.5 Non_tcp

When the active TCP connection count goes to zero, and non-TCP packets
are being transmitted, if no packets have been sent or received within
"Tcp_close" seconds, PPP is terminated and the interface is marked as DISCON.

5.2.2 Protocols

We can limit the calls made by the protocol.  Here is a sample access
file entry that would only allow tcp, udp, and icmp packets:

    protocols    tcp udp icmp

The keyword "goodprotocols" can be used in place of "protocols".
In addition, the keyword "badprotocols" can be used to disallow calls
based on packets certain protocols.

Any protocol that is in the "/etc/protocols" file is a valid entry on this
line.  Please note that this only controls the initiation of a call request.
Once a call succeeds, other protocols can be transmitted.

5.2.3 Times

By default, calls can be placed at any time.  If you wish to limit calls
during certain hours of certain days, you can place entries in the access
files containing the day and the hours when calls are should not be permitted.
The allowable days are:

    sun    sunday
    mon    monday
    tue    tuesday
    wed    wednesday
    thu    thursday
    fri    friday
    sat    saturday
    weekdays
    weekends

For instance, if calls should only be allowed during "business" hours of
monday through friday (8-5), with no calls in the evening or weekends,
you would use the following entries:

    weekdays    0 1 2 3 4 5 6 7 17 18 19 20 21 22 23 24
    weekends    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

If a day is not mentioned either explicitly or via the weekday/weekend
keyword, then calls can be placed all day.

To allow calls only during times with lower rates, one might want to turn
off calls during the 8-5 business day.  This would be done with the following
line:

    weekdays    8 9 10 11 12 13 14 15 16

Calls would then be placed anytime before 8AM and after 5PM on weekdays
and any time on weekends.

5.2.4 Hosts/Networks

To limit calls when certain hosts are involved, you can use further keywords.

In order to limit calls to packets which are destined to a list of specific
hosts, you would use the "allowto" (or equivalently "gooddstaddresses")
keyword.  If the access file has a line of this form, a call will fail for
packets having destination addresses not in this list.  So, if we wish
calls to be placed for only one hosts on the 192.100.10.0 network and the
goodhost.com host, a line of the following form would be used:

    allowto    192.100.10.0 goodhost.com

In order to limit where a packet may come from, you can use the "disallowfrom"
(or equivalently "badsrcaddresses") keyword.  If a call request is made
for a packet coming from an address in this list, then the call fails.
An example would be

    disallowfrom    badhost.edu

The addresses given in these lists can be the name of a network, the
name of a host, or equivalently an internet host or network address in
dot notation.

5.3  Script Files

The script mechanism is used by the dpd program to interact with modems
and systems to make calls and log in to remote computers.  They provide a
full send-expect style facility, with many extensions to allow for
timeouts, alternative choices and others.  This is a direct extension
of the DialupIP 2.0 script file mechanism with the following additions:

- Two separate scripts are required for dialing and for login.

- Timeouts can be 0 to indicate matches of previously received data (via a
  mark/replay command pair).

- "recv" commands can match more than one alternative string

Script files contain a sequence of lines, each with a command and zero or
more arguments.  Blank lines and lines beginning with # are ignored.
Strings must be quoted with double quotes (") if they contain white space.
Standard C escape sequences are valid (\b, \f, \n, \r, \t, or \000 where 000
is any octal number).

Several example script files are provided in the distribution for dialing
several different Telebit modems directly into a remote system as follows:

t1600-dial    Dials the given number on a Telebit T1600 modem.
t3000-dial    Dials the given number on a Telebit T3000 modem.
wb-dial        Dials the given number on a Telebit WorldBlazer modem.
ppp-login    Logs into a remote system directly.  The first argument
        is a login, and the second argument is the password.
        This assumes the login shell on the remote system is "dplogin",
        and performs simple synchronization with that program.

5.3.1 abort

The "abort" command terminates the script with a failure code returned.
Reading the script past the end of file is equivalent to the "abort" command.

5.3.2 go

The "go" command indicates success.  For a dial script, success means
that the call went through using the specific modem.  For a login script,
success means that PPP is started on the remote computer.

5.3.3 log "text"

This writes the given string to the log file (by default, /var/adm/dp/dp.log).

5.3.4 mark

As incoming bytes are received, they are saved in a buffer for possible later
use by "replay".  The mark command indicates the beginning of where to start
saving characters.

5.3.5 replay

Characters in the incoming buffer are replayed as if they are being received
again.  This replay starts at the most recent mark command.

5.3.6 recv "text" [ "text" ... ] timeout

The recv command is used to examine the incoming characters (which can be
actual new characters, or older ones after a replay command.  The command
succeeds when a substring of the incoming characters matches one of the
"text" patterns given.  If the match has not succeeded in "timeout" seconds,
the "recv" command returns failure.  However, if the "recv" command is in
a "select block", control is passed to the next alternative.

5.3.7 use script [ "parameter" ... ]

The use command executes another script file and returns success or failure
depending on the execution of the named script.

5.3.8 xmit "text"

This sends the indicated text to the remote system.  A \x in the string
will delay 1 second, and a \# will send a break.
Also, the string $1 will be replaced by the first argument to the script,
and so on.  The arguments are given in the dp-conf file or as arguments
the the "use" command.

5.3.9 Select Blocks

Select blocks allow you to specify alternatives on failure of specific
"recv" commands.

The format is as follows:

    {
    alternate
        commands...
    alternate
        commands...
    }

The "{", "}", and "alternate" keywords are commands and must be on separate
lines.  If a "recv" command fails, then control is passed to the next
alternate.  If all alternatives fail, then the select block returns a
failure, and is equivalent to an "abort".

6.  Routing

There are two ways, in general, that you will connect systems
together with dp. The first is a single machine (typically at home)
to a network of systems (the office network or maybe the Internet)
and second to connect two networks (two sites for example, or an
office network to the Internet).

In either case, the networking software has to know how to get to the
"other" systems. This is done in the kernel by routing tables. There
is at least one route to each interface, but the administrator (you)
can add more.

6.1 Static Routing

Where there is a single machine and a remote network or two
reasonably stable networks which are under your administrative
control, then the simplest way of setting things up is to use static
routes.

Again, in the Unix way there is always more than one way of doing
things, and this is true for installing route into the kernel.

6.1.1 "route"

The most direct way to install a new route is the use the route(8)
command. "route" will allow you, as superuser, to add and delete
routes in the kernel. There are three (really two) types of route:

*    Route to a host. This type of route effectively says: you can get
to this host via this interface.

*    Route to a network. This type says there is a network over there,
past that interface on the left :-)

*    The default route. The is a special route that is used as a catch
all. It is most useful for a single host (home) connecting to
everything else and tells the networking software to route everything
down a single line if the is no other explicit route for it.

As an example, let's say that a home system is connected to a work system
via a PPP link.  "home.com" has the PPP interface of 192.220.10.1
"work.com" has the PPP interface 192.220.10.2 and the ethernet interface
192.220.11.18.  In order to another machine on the work ethernet to get to
the home system, it would need the command

    /usr/etc/route add 192.220.10.1 192.220.11.18 1

In order for the home system to reach other hosts on the work ethernet,
it would need the command:

    /usr/etc/route add 192.220.11.0 192.220.10.2 1

Assume now that the ethernet is connected to other networks or the Internet.
Then, the best command for home.com would be:

    /usr/etc/route add default 192.220.10.2 1

This would route all remote packets through the PPP interface.

6.1.2 "/etc/gateways"

The other method is to create a file called "/etc/gateways" that
lists static route available at boot time (more correctly when the
routing daemon is started).

This file is read when "in.routed" is started in "/etc/rc.local".
For further information, see the routed(8c) manual page.

6.2 Dynamic Routing

In the case where two networks are connected, and these may have
further connections added to them or taken away,  then there must be
a way for the routing information to be updated at regular intervals
so that packets can get to their intended destinations.

6.2.1 Routed

Routed(8c) has been used extensively for adapting routes to changing network
connectivity.  It will work in this case of PPP links.  Routed works by sending
RIP packets (Routing Information Protocol) on every interface every 30 seconds.
Clearly, if we wish to disconnect the phone when our interface is not in use,
this will cause problems.  For this reason, routed is probably not the best
choice for routing on hosts with dialup PPP interfaces, unless the intent
is to keep the phones connected all the time.

6.2.1 Gated

Gated is a program that knows about routing via several protocols.
It can handle RIP (routed) packets, as well as other protocols such
as EGP (External Gateway Protocol) and GGP (Gateway to Gateway Protocol).
It also can be used to consider certain routes as "static" and to be always
available.  These routes can then be advertised using any of the available
routing protocols, including RIP.

If you have RIP based routing, then gated can be easily set up on your
hub machine up to use static routing for the PPP links and use RIP for
the other (ethernet?) networks.

Here is an example gated configuration file for our campus hub that talks
to 6 remote systems, each with a local ethernet at the other end:

    #
    #    Config file gated on phoenix.acn.purdue.edu
    #
    traceoptions internal external route rip update ;
    #tracefile "/tmp/gated.trace" ;

    interface all passive ;        # don't time out my interfaces!

    #
    # Do rip except on the PPP interfaces
    #
    rip supplier {
    interface dp0 noripout noripin ;
    interface dp1 noripout noripin ;
    interface dp2 noripout noripin ;
    interface dp3 noripout noripin ;
    interface dp4 noripout noripin ;
    interface dp5 noripout noripin ;
    } ;

    #
    # Set up static routes to remote ethernets at the end of PPP links
    # We are advertising ourself as a gateway to the subnetwork assigned
    # to the PPP links.  For each remote ethernet, the remote end of a PPP
    # link is being advertised as a gateway.
    #
    static {
    128.46.177.0 gateway 128.46.157.167 ;    # PPP Links
    128.46.34.0  gateway 128.46.177.34 ;    # Remote ethernet
    128.46.181.0 gateway 128.46.177.43 ;    # Remote ethernet
    128.46.176.0 gateway 128.46.177.49 ;    # Remote ethernet
    128.46.182.0 gateway 128.46.177.50 ;    # Remote ethernet
    128.46.84.0  gateway 128.46.177.84 ;    # Remote ethernet
    } ;

    #
    # Send out all sorts of interesting information in RIP packets
    #
    propagate proto rip {
    #
    # Propagate anything learned via RIP
    #
    proto rip ;
    #
    # Propagate static routes to county ethernets
    # Technically, the metric for remote ethernets should be 2,
    # but 1 works better in this scenario since there are no alternate
    # routes anyway, especially direct routes.
    #
    proto static metric 1 ;
    #
    # Propagate routes to all connected interfaces
    #
    # proto direct metric 1 ;
    } ;

    #
    # We don't have SNMP configured in
    #
    #snmp no ;

We are using gated 2.1 and it is available via anonymous ftp from
gated.cornell.edu in the file "pub/gated/gated/gated.tar.Z".
It works quite well in our configuration.

7. Tuning

You need to set up your "/etc/dp/config/dp-conf" file and any script
and access files for what makes sense in your environment.  The primary
tuning comes in getting your dialing scripts to work, selecting appropriate
timeouts in your access file, and monitoring what happens.

The file /var/adm/dp/call.log can be used to give you a one line
summary of each successful call.  The file /var/adm/dp/dp.log can be used
to show you a blow by blow description of calls in progress.  The amount
of logging can be increased by invoking dpd with "-d N" where N can be anywhere
from 0 for minimal logging to 3 for verbose logging.  In addition, the log
level can be set for individual systems in the configuration file.

If you encounter problems with the kernel modules, you can turn on very
verbose debugging output by setting the following kernel variables:

dpif streams module
    dp_if_debug            General info
    dp_ftimo_debug        Fast timeout mechanism
    dp_active_debug        TCP connection status

pppdial streams module
    ppp_dial_debug        General info

pppasync streams module
    ppp_async_debug        General info
    ppp_async_input_debug    input packet dump of N bytes

These variables are all "int" variables and should be set to 0 or 1, to have
the reporting off or on, respectively.  The ppp_async_input_debug variable
can be given a value greater than 1 to indicate the number of bytes printed in
a packet trace.

As an example, to set ppp_async_input_debug variable to 32, run
"adb -k -w /vmunix /dev/mem".  Then, type "ppp_async_input_debug/W0t32",
then to get out of adb, type a control-D.

7.1 Broadcast programs

Some programs broadcast information on a regular basis to all connectected
interfaces.  If a program is found to generate frequent output on PPP
interfaces, it should be reconfigured, modified, or just not run at all,
depending on the circumstances.

7.1.1 rwhod

A common example of a talkative program is rwhod.  If you must run rwhod,
it should be modified to ignore PPP links.  Context diffs for rwhod are
available on phoenix.acn.purdue.edu in pub/rwhod.diffs.Z.  Once applying
these diffs to rwhod sources, you should be able to run rwhod with the
"-p" flag to suppress all output on Point to Point interfaces.

7.2 Nameserver

If you are on the Internet, you pretty much are mandated to use DNS.
If you are relying solely on DNS (no NIS or host tables), you should
set up nameservers at the remote sites. Care should be taken in the
configuration of the nameservers.  There are at least a couple of ways
that you can set things up.

7.2.1 Secondary nameservers

You can set up secondary nameservers on each of the remote sites.
They can zone load your organization wide zones on a regular basis.
Please note that zones have a refresh time at which point a connection
will be made to check for updates.  This can vary, but it may be 12 hours
or so.  This interval is specified in the zone file on the primary nameserver.
At this interval, the remote secondary nameserver will contact the primary
nameserver (generating a call in our case).  It will verify that it has
the most recent version of each zone of interest.

7.2.2 Primary nameservers

For remote sites that are placing toll calls, a refresh interval of 12
hours would result in 2 extra toll calls per day.  This may be a problem.
If so, consider making the remote system a primary nameserver.  When the
central nameserver file is updated, it needs distributed to all remote
primary nameservers, but this may be manageable compared to all the long
distance toll charges of the more automatic scheme employed by the secondary
nameservers.

In general the remote primary servers should not be listed in the
nameserver data contained in the zone data.  Otherwise, distant Internet hosts
may try to use them for information about the zone, generating unnecessary
traffic.  They should exist as primary nameservers, but not be advertised
as such.

8. Future work

A few areas are slated for future work as time permits.

We will continue to track the Point to Point Protocol as it is updated
and newer versions are made available

With slow links, there are some problems with the combination of
bursty interactive traffic and large batch file transfer traffic.
A future release will implement Type of Service (TOS) priority queueing
to give priority to interactive packets.  This should help interactive
response on heavily loaded links.

We would like to add some administrative tools that can give a better
picture of the traffic patterns over periods of time.  For instance,
it would be useful to have a report showing how many calls were placed
for what protocol, sorted by number of calls, for a given month.

Peter Galbavy is now working on modifications to do synchronous 64 Kbps
with the SPARCstation on board serial port.

Further updates to this document will be made as we get feedback from
people using the software.

Support for other platforms will be integrated as interested parties provide
the ports.

Support for Solaris 2.0 will come as it becomes generally available.

9. Credits

The bulk of the work has been done at Purdue University by Kirk Smith
([e-mail]) and has been supported by the Purdue Agricultural
Computer Network.  The Purdue ACN is responsible for networking 96
remote computers to the campus internet.  Right now, 5 remote sites are
in operation and more will come on line as Sun equipment is purchased.

Peter Galbavy of Micromuse Ltd. ([e-mail]) has provided
invaluable help in several areas.  Among these, were the loadable module
support, integration of newer PPP revisions, significant work on this document,
and much testing and several bug fixes.